<html>
<head><meta charset="utf-8"><title>Incremental Approach · project-safe-transmute · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/index.html">project-safe-transmute</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html">Incremental Approach</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="218232202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218232202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218232202">(Nov 29 2020 at 21:44)</a>:</h4>
<p>As I was falling asleep last night, I was thinking about whether a much more incremental approach might help cut down the RFC significantly.</p>
<p>Concretely, we reduce the <em>initial</em> proposal to <em>just</em> this:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[derive(PartialEq, Eq)]</span><span class="w"></span>
<span class="cp">#[non_exhaustive]</span><span class="w"></span>
<span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Neglect</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="n">alignment</span><span class="w">   </span>: <span class="kt">bool</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="n">lifetimes</span><span class="w">   </span>: <span class="kt">bool</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="n">validity</span><span class="w">    </span>: <span class="kt">bool</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="n">visibility</span><span class="w">  </span>: <span class="kt">bool</span><span class="p">,</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>

<span class="k">impl</span><span class="w"> </span><span class="n">Neglect</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="k">const</span><span class="w"> </span><span class="n">NOTHING</span>: <span class="nc">Self</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">Neglect</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="n">alignment</span><span class="w">   </span>: <span class="nc">false</span><span class="p">,</span><span class="w"></span>
<span class="w">        </span><span class="n">lifetimes</span><span class="w">   </span>: <span class="nc">false</span><span class="p">,</span><span class="w"></span>
<span class="w">        </span><span class="n">validity</span><span class="w">    </span>: <span class="nc">false</span><span class="p">,</span><span class="w"></span>
<span class="w">        </span><span class="n">visibility</span><span class="w">  </span>: <span class="nc">false</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="p">};</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>

<span class="k">pub</span><span class="w"> </span><span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">is_transmutable_from</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Dst</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">(</span><span class="n">_</span>: <span class="nc">Neglect</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="kt">bool</span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="cm">/* compiler intrinsic */</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="218232302"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218232302" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218232302">(Nov 29 2020 at 21:47)</a>:</h4>
<p><a href="https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=9b5551f37af7c4dbda51502e9f99ea26">*Everything* else we've discussed can be built on that foundation.</a></p>



<a name="218234776"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218234776" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218234776">(Nov 29 2020 at 22:52)</a>:</h4>
<p>i wonder if Neglect being a parameter makes sense? when would you dynamically determine those things? and how would that work</p>



<a name="218234783"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218234783" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218234783">(Nov 29 2020 at 22:53)</a>:</h4>
<p>It feels like it works more as a const parameter, i mean.</p>



<a name="218234784"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218234784" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218234784">(Nov 29 2020 at 22:53)</a>:</h4>
<p>But perhaps thats too far off.</p>



<a name="218234840"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218234840" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218234840">(Nov 29 2020 at 22:54)</a>:</h4>
<p>No, that's a really good observation. It <em>should</em> be a const param, I think.</p>



<a name="218235031"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218235031" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218235031">(Nov 29 2020 at 23:00)</a>:</h4>
<p>Besides that, I really like this. It's very simple and is relatively clear how to build stuff on top of it. I've struggled to understand some of the earlier proposals despite being the author of a few of <code>bytemuck</code>'s traits (So if nothing else I'm somewhat aware of the design space), but find this a lot simpler and more clear.</p>



<a name="218239575"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239575" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239575">(Nov 30 2020 at 00:57)</a>:</h4>
<p>This would mandate const generics for some use cases that wouldn't need them with the more complex approach, right?</p>



<a name="218239579"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239579" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239579">(Nov 30 2020 at 00:57)</a>:</h4>
<p>Also, I feel like Neglect isn't the complex part of the RFC. <code>Here!</code> is.</p>



<a name="218239644"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239644" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239644">(Nov 30 2020 at 00:59)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218239579">said</a>:</p>
<blockquote>
<p>Also, I feel like Neglect isn't the complex part of the RFC. <code>Here!</code> is.</p>
</blockquote>
<p>That's fair, although this is simpler in that it boils the complex thing down to just that, as opposed to that + a family of traits.</p>



<a name="218239649"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239649" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239649">(Nov 30 2020 at 00:59)</a>:</h4>
<p>I'm not trying to simplify <code>Neglect</code> with this incremental suggestion—we need to wrestle with how that's encoded regardless.</p>



<a name="218239722"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239722" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239722">(Nov 30 2020 at 01:01)</a>:</h4>
<p>Er, <code>Here!()</code> isn't part of this suggestion.</p>



<a name="218239796"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239796" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239796">(Nov 30 2020 at 01:03)</a>:</h4>
<p>Scope is tho, which is what <code>Here!()</code> is for, no?</p>



<a name="218239871"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218239871" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218239871">(Nov 30 2020 at 01:04)</a>:</h4>
<p><span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span>  <code>Here!()</code> is just an ergonomic device. It's totally not central and it'd perhaps be best if we forgot I suggested it. ;)</p>
<p><code>Scope</code> works like so:</p>
<ul>
<li>If validity is being neglected, set <code>Scope</code> to anything. It's totally ignored.</li>
<li>If validity <em>isn't</em> being neglected, <code>Scope</code> should be instantiated with some private type. The compiler then pretends it's at the definition site of that private type, and checks to see whether the necessary fields of <code>Src</code> and <code>Dst</code> are visible at that location.</li>
</ul>
<p>It's what lets us answer the question of transmutation safety <em>without</em> wrestling with the design of manually implemented traits that <em>also</em> carry stability connotations.</p>



<a name="218240181"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218240181" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218240181">(Nov 30 2020 at 01:12)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> For me, the complex part of safe transmutation is devising a satisfactory way to communicate layout semver stability. I think we're approaching a solution for one class of transmutations and stability guarantees, but there's a lot of work yet to do to work out the details, and there are <em>lots</em> of others situations we haven't yet addressed. All of these have <em>super</em> subtle tradeoffs.</p>



<a name="218240464"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218240464" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218240464">(Nov 30 2020 at 01:21)</a>:</h4>
<p>Yeah, I figured it was something like that. That's a bit odd since nothing like that exists in rust currently, but hm, okay.</p>



<a name="218240542"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218240542" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218240542">(Nov 30 2020 at 01:23)</a>:</h4>
<p>Heh, it's a bit unusual, but so is an intrinsic that reasons about the safety of transmutations. <span aria-label="smile" class="emoji emoji-1f642" role="img" title="smile">:smile:</span></p>



<a name="218251429"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218251429" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218251429">(Nov 30 2020 at 05:58)</a>:</h4>
<p>I don't see how removing <code>Here!()</code> but not <code>Scope</code> is any less fundamentally complex. And <code>Here!()</code> being "just an ergonomic device" only backs that up...</p>



<a name="218253083"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218253083" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218253083">(Nov 30 2020 at 06:40)</a>:</h4>
<p>I think it only working for public types would be unfortunate. That's an issue I always had with the bytemuck design (<code>ref_cast</code> has the same issue). <code>Scope</code> solves that problem in a way that seems explainable relatively simply, I wasn't really aware of what it did before <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218239871">this</a>, and that doesn't seem that bad for a low level building-block that a higher level api can be built on top of.</p>



<a name="218311690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218311690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218311690">(Nov 30 2020 at 16:42)</a>:</h4>
<p>The point is, again, private impls are a whole other problem space. It's really out of scope for the safe transmute RFC to try to solve that problem too- it should be addressed head-on, not as a side issue for something else.</p>



<a name="218311780"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218311780" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218311780">(Nov 30 2020 at 16:43)</a>:</h4>
<p>And it's not like there aren't workarounds! Leaving the private impl question for future work doesn't block safe transmute, it just means some use cases will have some boilerplate. And that boilerplate already happens elsewhere, it's not new or unique.</p>



<a name="218312206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218312206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218312206">(Nov 30 2020 at 16:46)</a>:</h4>
<p>Look, we could also solve safe transmute by first providing a general mechanism that reflects the structure or layouts of types, or by first providing a stable compiler plugin mechanism. Instead, we're providing a somewhat magical transmutability intrinsic—we <em>don't</em> need to wait to first solve these big problems in-the-large.</p>



<a name="218312262"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218312262" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218312262">(Nov 30 2020 at 16:47)</a>:</h4>
<p>Anyways, the <code>Muckable*</code> approach is unsuitable for a lot of use-cases I'm interested in exploring.  <span aria-label="sad" class="emoji emoji-2639" role="img" title="sad">:sad:</span>  It's not just a matter of boilerplate!</p>



<a name="218312956"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218312956" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218312956">(Nov 30 2020 at 16:51)</a>:</h4>
<p>And the existence of a more foundational API <em>doesn't</em> preclude the existence of a scope-unaware <code>Muckable*</code> abstraction!</p>



<a name="218313143"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218313143" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218313143">(Nov 30 2020 at 16:52)</a>:</h4>
<p>The difference is that we would presumably want to keep the Muckable stuff around forever, as an easier/simpler API on top of whatever the full version is. But we definitely <em>don't</em> want to keep <code>Scope</code> around forever, we want it not to exist at all.</p>



<a name="218313290"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218313290" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218313290">(Nov 30 2020 at 16:53)</a>:</h4>
<p>This is getting into the same problem that the initial RFC did- targeting a big set of use cases at any cost, without really clarifying whether those use cases are worth it or whether the cost is even on the table.</p>



<a name="218313609"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218313609" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218313609">(Nov 30 2020 at 16:55)</a>:</h4>
<p>I suspect the discussion would benefit from more presentation of motivating use cases, so that more brains can consider solutions for them.</p>



<a name="218313728"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218313728" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218313728">(Nov 30 2020 at 16:56)</a>:</h4>
<p>I've been trying to follow all of this pretty closely but I still feel like every discussion ends with "but &lt;this other use case&gt;" that I wasn't aware of. :/</p>



<a name="218313738"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218313738" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218313738">(Nov 30 2020 at 16:56)</a>:</h4>
<p><span class="user-mention silent" data-user-id="117495">rpjohnst</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218313143">said</a>:</p>
<blockquote>
<p>But we definitely <em>don't</em> want to keep <code>Scope</code> around forever, we want it not to exist at all.</p>
</blockquote>
<p><strong>I categorically disagree.</strong> There's a <em>lot</em> of discussion in the <a href="#narrow/stream/216762-project-safe-transmute/topic/UnstableTransmuteFrom">UnstableTransmuteFrom topic</a> about:</p>
<ul>
<li>why an explicit <code>Scope</code> parameter might be fundamentally necessary</li>
<li>how it fits into rust's existing impl privacy rules</li>
<li>how we can elide the parameter in the future if someone, someday figures out the deep issues with an implicit impl privacy system</li>
</ul>



<a name="218314407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218314407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218314407">(Nov 30 2020 at 17:01)</a>:</h4>
<p>Nothing in that topic convinced me that <code>Scope</code> is fundamentally necessary. <code>FromZeros</code> would work perfectly fine without it, using the newtype pattern to export a type without exporting its <code>FromZeros</code> impl.</p>



<a name="218320190"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218320190" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218320190">(Nov 30 2020 at 17:44)</a>:</h4>
<p>I'd like to avoid derailing every topic with this discussion, so I'm going to create a distinct topic for every scenario.</p>



<a name="218342116"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218342116" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Nick12 <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218342116">(Nov 30 2020 at 20:34)</a>:</h4>
<p>(deleted)</p>



<a name="218508517"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508517" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508517">(Dec 02 2020 at 02:27)</a>:</h4>
<p><span class="user-mention" data-user-id="117495">@rpjohnst</span> did you catch that this proposal <em>isn't</em> suggesting a trait?</p>



<a name="218508537"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508537" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508537">(Dec 02 2020 at 02:27)</a>:</h4>
<p>Yes. ???</p>



<a name="218508588"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508588" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508588">(Dec 02 2020 at 02:28)</a>:</h4>
<p>Sorry, you were referencing the <code>UnstableTransmuteFrom</code> trait in some of your recent messages. I just wanted to be clear that's not what's being proposed here.</p>



<a name="218508605"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508605" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508605">(Dec 02 2020 at 02:29)</a>:</h4>
<p>Well those messages don't really change if you replace <code>UnstableTransmutableFrom</code> with <code>const fn is_trasnmutable_from</code> do they.</p>



<a name="218508630"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508630" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508630">(Dec 02 2020 at 02:29)</a>:</h4>
<p>Some of them do, I think. People <em>do</em> have an expectation that trait implementations have stability connotations. They don't have this expectation for the <code>mem</code> intrinsics.</p>



<a name="218508710"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508710" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508710">(Dec 02 2020 at 02:31)</a>:</h4>
<p>Perhaps that's fair, but in that case why include <code>Scope</code> at all? Why not just have the <code>const fn</code> ignore visibility entirely like the other <code>mem</code> intrinsics?</p>



<a name="218508775"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508775" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508775">(Dec 02 2020 at 02:32)</a>:</h4>
<p>Does the size or alignment of a type depend on scope?</p>



<a name="218508779"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508779" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508779">(Dec 02 2020 at 02:32)</a>:</h4>
<p>No, but neither does a type's layout.</p>



<a name="218508783"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508783" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508783">(Dec 02 2020 at 02:32)</a>:</h4>
<p>In contrast, the visibility of a field <em>does</em> matter as to whether you can safely fiddle with it.</p>



<a name="218508792"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508792" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508792">(Dec 02 2020 at 02:32)</a>:</h4>
<p>But the scope is totally insufficient to determine whether a transmute is actually safe/visible.</p>



<a name="218508817"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508817" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508817">(Dec 02 2020 at 02:33)</a>:</h4>
<p>We'd be right back in the same place as <code>trait UnstableTransmuteFrom</code>.</p>



<a name="218508823"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508823" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508823">(Dec 02 2020 at 02:33)</a>:</h4>
<p>Whereby "actual safe/visible", you mean: "The type author has declared it to be semver stable."</p>



<a name="218508826"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508826" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508826">(Dec 02 2020 at 02:33)</a>:</h4>
<p>Exactly.</p>



<a name="218508977"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218508977" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218508977">(Dec 02 2020 at 02:36)</a>:</h4>
<p>That's just <em>not</em> what "safe" typically means, though. I'm using "safety" it in the typical sense of <em>cannot cause memory unsoundness or compiler UB</em>. (cc <span class="user-mention" data-user-id="120791">@RalfJ</span>, since I'm probably mis-paraphrasing him here.)</p>



<a name="218509089"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218509089" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218509089">(Dec 02 2020 at 02:39)</a>:</h4>
<p>But it is- these things are connected! Consumer code (including unsafe consumer code) ought to be able to rely not only on the continued validity of a transmutation (it would at least stop compiling if that were the only problem) but on its meaning. Take the <code>Packet</code>/<code>Header</code> example- what if <code>Header</code>s fields are reordered (or <code>Packet</code> replaces its <code>Header</code> with <code>HeaderWithReorderedFields</code>) but it's still a <em>valid</em> transmute on its own? Now if I actually use the <code>Header</code> for something that would be sound with the original version, it may no longer be sound.</p>



<a name="218509295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218509295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218509295">(Dec 02 2020 at 02:42)</a>:</h4>
<p>This is why safety and visibility and semver are connected, and not totally separable. Something can only be sound if unsafe code's assumptions aren't violated, but those assumptions can be violated by seemingly-innocuous changes if suddenly external code can rely on those changes not happening.</p>



<a name="218509454"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218509454" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218509454">(Dec 02 2020 at 02:45)</a>:</h4>
<p>And now that Rust has been around a while, we have to further keep in mind that some of those changes <em>already happen across versions.</em> There are already crates out there that change field order in minor releases, so providing a tool like <code>UnstableTransmutableFrom</code> or <code>is_transmutable_from</code> that makes field order visible is just asking for trouble.</p>



<a name="218510487"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218510487" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218510487">(Dec 02 2020 at 03:07)</a>:</h4>
<p><span class="user-mention silent" data-user-id="117495">rpjohnst</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218509295">said</a>:</p>
<blockquote>
<p>This is why safety and visibility and semver are connected, and not totally separable.</p>
</blockquote>
<p>That is not fully the case. For example, iirc the UGC opinion on unsafely creating a DST or a slice via transmute is that if you guess the field order right, there's no UB. It's unspecified behavior, not undefined. This is different from say, guessing the stack position of a local variable or the address of a call to malloc, which is UB no matter what.</p>



<a name="218510495"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218510495" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218510495">(Dec 02 2020 at 03:08)</a>:</h4>
<p>They are connected in the sense that you <em>must not rely on unspecified behavior for the soundness of safe code</em>. But this is just  the reality we live in. It's not <em>just</em> <code>size_of</code>, or <code>align_of</code>, or <code>as</code> casting, it's with <code>sort_unstable</code> and <code>Range</code> edge-cases — with <em>anything</em> that introduces unspecified behavior. If you are writing unsafe code, the burden is on <em>you</em> to not rely on unspecified behavior.</p>
<p>Unspecified behavior <em>isn't</em> evil. It's a fundamentally useful programming tool. Their existence isn't "asking for trouble". The fact that someone <em>might</em> incorrectly rely on <code>align_of</code> or <code>sort_unstable</code> isn't a convincing argument against the existence of those constructs.</p>



<a name="218532666"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218532666" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218532666">(Dec 02 2020 at 09:32)</a>:</h4>
<p>What is it you plan to keep unspecified? While I agree the burden is on the unsafe code to not make assumptions not guaranteed by its dependencies, I'd also say that a transmute which just produces an unspecified value of the target type is not very useful.</p>



<a name="218553346"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218553346" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218553346">(Dec 02 2020 at 13:13)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> <code>UnstableTransmuteFrom</code>/<code>is_transmutable</code> would be by-default SemVer unspecified, similar to the other <code>mem</code> intrinsics.</p>



<a name="218554165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218554165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218554165">(Dec 02 2020 at 13:19)</a>:</h4>
<p>I don't know what this means or how it relates to other <code>mem</code> intrinsics</p>



<a name="218557214"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218557214" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218557214">(Dec 02 2020 at 13:44)</a>:</h4>
<p>Sorry. <code>mem::align_of</code> tells you the minimum alignment of a type, but there's no connotation that that output value will remain static across SemVer minor changes to that type.</p>
<p>Similarly, UnstableTransmuteFrom/is_transmutable would tell you whether a bit-reinterpretation cast is well defined and safe—but not whether that will remain true across SemVer minor changes.</p>
<p>(I'm not arguing against layout stability systems, to be clear. Just that this API would be a broadly useful initial foundation for layout stability abstractions.)</p>



<a name="218569845"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218569845" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218569845">(Dec 02 2020 at 15:12)</a>:</h4>
<p>right... I feel there is still confusion here about the two very different usecases where the compiler can help with transmutations:</p>
<ul>
<li><em>inside</em> a library, with full control over both types</li>
<li><em>across</em> library boundaries, where at least one involved type is in a different crate (or more generally a "different semver domain", if that makes any sense)</li>
</ul>
<p>I gather from <span class="user-mention" data-user-id="117495">@rpjohnst</span> 's response to the message where you pinged me that they are thinking of the 2nd case, where your last messages here are clearly about the first case.</p>



<a name="218570248"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218570248" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218570248">(Dec 02 2020 at 15:15)</a>:</h4>
<p>(or maybe I am misunderstanding things here... I got pinged so I am trying to understand what the question is about but I didnt have time to read the entire pretty long backlog, sorry)</p>



<a name="218576980"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218576980" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218576980">(Dec 02 2020 at 15:59)</a>:</h4>
<p>Yes, I believe you're understanding things. I think <span class="user-mention" data-user-id="117495">@rpjohnst</span>'s position is that items with semver unspecified behavior (e.g., <code>size_of</code>, <code>align_of</code>) are historical mistakes that shouldn't be repeated because they can lead to unsafety. Rust therefore must not provide a compiler-implemented intrinsic for assessing transmutability that doesn't require SemVer opt-in.</p>



<a name="218580991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218580991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218580991">(Dec 02 2020 at 16:24)</a>:</h4>
<p>No, you've read me <em>way</em> too broadly. I have no problem with <code>sort_unstable</code>, or typical <em>uses</em> of <code>align_of</code>, or even with an <code>is_transmutable</code> intrinsic per se! I have a problem with APIs that forcibly export new aspects of types that were previously non-breaking to change.</p>
<p>Going back a step in our discussion, I said this:</p>
<blockquote>
<p>in that case why include <code>Scope</code> at all? Why not just have the <code>const fn</code> ignore visibility entirely like the other <code>mem</code> intrinsics?</p>
</blockquote>
<p>Ralf's division suggests a better way to frame this. A version of the intrinsic that I would be totally okay with is one that is only usable inside a library, with <em>no way whatsoever</em> to use it across libraries without an opt-in. This is why I don't like <code>Scope</code>- it essentially <em>is</em> a layout stability system, but a very blunt and un-idiomatic one that is declared by fiat not to provide any actual visibility.</p>



<a name="218581317"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218581317" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218581317">(Dec 02 2020 at 16:26)</a>:</h4>
<p>Going back to the <a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Partial.20Visibility/near/218507058">"golden standard"</a> of visibility- given a primitive like <code>is_transmutable</code> that works <em>only</em> on validity and not visibility/safety, it is the job of the type author to call that intrinsic. If other libraries need that functionality, they should only be able to use it via some well-defined semver-stable interface.</p>



<a name="218581649"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218581649" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218581649">(Dec 02 2020 at 16:28)</a>:</h4>
<p>And frankly, I would characterize the <code>Scope</code> approach as the one conflating things here- it tries to tie visibility into the intrinsic, but that conflates validity (what the type author is allowed to do) with visibility (which is neither necessary nor sufficient to determine safety).</p>



<a name="218582244"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218582244" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218582244">(Dec 02 2020 at 16:32)</a>:</h4>
<p><span class="user-mention silent" data-user-id="303115">Quy Nguyen</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218510487">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="117495">rpjohnst</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218509295">said</a>:</p>
<blockquote>
<p>This is why safety and visibility and semver are connected, and not totally separable.</p>
</blockquote>
<p>That is not fully the case. For example, iirc the UGC opinion on unsafely creating a DST or a slice via transmute is that if you guess the field order right, there's no UB. It's unspecified behavior, not undefined. This is different from say, guessing the stack position of a local variable or the address of a call to malloc, which is UB no matter what.</p>
</blockquote>
<p>This is also a great illustrative example- guessing the field order means there's no UB in that compilation, because everything stays <em>valid.</em> But guessing the field order is certainly a violation of visibility and semver- if the field order changes it suddenly <em>is</em> UB. The unspecified behavior includes "UB in the future."</p>



<a name="218582671"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218582671" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218582671">(Dec 02 2020 at 16:35)</a>:</h4>
<p>Now, I fully understand the reason for <em>wanting</em> the <code>Scope</code> system- to let libraries extend the <code>is_transmutable</code> intrinsic with richer APIs that are still, themselves, unstable. These APIs would then be usable by type authors to "close the loop" and hide the instability <em>almost</em> entirely inside their library. But that doesn't mean I think that's a good approach.</p>



<a name="218582984"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218582984" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218582984">(Dec 02 2020 at 16:37)</a>:</h4>
<p>I apologize, though I'm not sure I'm clear. Isn't the typical use of <code>align_of</code> writing <code>unsafe</code> that depends on alignment?</p>



<a name="218583283"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583283" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583283">(Dec 02 2020 at 16:39)</a>:</h4>
<p>Well by "typical" I mean things like allocators, which can handle any value for <code>align_of</code> and will simply adjust if it changes.</p>



<a name="218583514"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583514" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583514">(Dec 02 2020 at 16:41)</a>:</h4>
<p>I don't think pointer bitpacking is an <em>atypical</em> use of <code>align_of</code>.</p>



<a name="218583537"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583537" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583537">(Dec 02 2020 at 16:41)</a>:</h4>
<p>It's certainly less common than allocators ;)</p>



<a name="218583573"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583573" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583573">(Dec 02 2020 at 16:41)</a>:</h4>
<p>But I don't mind picking a different word, my point was about the use cases and not how common they are.</p>



<a name="218583586"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583586" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583586">(Dec 02 2020 at 16:41)</a>:</h4>
<p>And things that involve <code>size_of</code> are quite often either <em>they work or they don't</em> (e.g., does a type fit into a buffer or not).</p>



<a name="218583720"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583720" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583720">(Dec 02 2020 at 16:42)</a>:</h4>
<p>Wellllll the "good" use of <code>size_of</code> is to <em>determine</em> the size of that buffer to begin with.</p>



<a name="218583792"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583792" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583792">(Dec 02 2020 at 16:43)</a>:</h4>
<p>Using it to "guess" that a type will stay a particular size across versions when that's not part of the type's API is questionable.</p>



<a name="218583981"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218583981" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218583981">(Dec 02 2020 at 16:44)</a>:</h4>
<p>I don't see that it's used to guess any such thing. Rather, it's used to enforce a safety invariant.</p>



<a name="218584107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218584107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218584107">(Dec 02 2020 at 16:45)</a>:</h4>
<p>If it matters that the size is stable <em>across</em> versions, you either need to look towards documentation, marker traits or other indicators (like that the type is fully implicitly constructible).</p>



<a name="218584465"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218584465" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218584465">(Dec 02 2020 at 16:47)</a>:</h4>
<p>Perhaps "guess" was also an imprecise word. My point is, I don't mind people using <code>size_of</code> or <code>align_of</code> in ways that adapt to changes in their values- that's basically no different than e.g. field access syntax. I grit my teeth and accept people using them to enforce <em>documented</em> assumptions, because unfortunately we don't have a better alternative. But I don't like people using them to enforce <em>undocumented</em> assumptions, because that means they are liable to stop compiling in the face of changes that should have been non-breaking.</p>



<a name="218584548"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218584548" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218584548">(Dec 02 2020 at 16:48)</a>:</h4>
<p>And thus I also object to adding new APIs that can be used the same error-prone way.</p>



<a name="218584972"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218584972" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218584972">(Dec 02 2020 at 16:51)</a>:</h4>
<p>Okay, so this objection isn't specific to scope awareness. A scope-<em>unaware</em> <code>is_transmutable</code> would pose the same hazard, too. (E.g., the <code>NeglectSafety</code>-like option discussed in the RFC comments.)</p>



<a name="218585392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218585392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218585392">(Dec 02 2020 at 16:54)</a>:</h4>
<p>Right, I don't want a scope-<em>unaware</em> intrinsic but a <em>current-scope-only</em> intrinsic.</p>



<a name="218585501"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218585501" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218585501">(Dec 02 2020 at 16:54)</a>:</h4>
<p>(And that excludes other scopes that can see some or all fields.)</p>



<a name="218585551"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218585551" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218585551">(Dec 02 2020 at 16:55)</a>:</h4>
<p>(So perhaps I should say "make layout fully private rather than tying it to field or type visibility."</p>



<a name="218585767"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218585767" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218585767">(Dec 02 2020 at 16:56)</a>:</h4>
<p>When you say "current scope only", then what visibility matters? That the fields must be visible in the scope of the transmutation? That the types must be visible in the scope of the transmutation?</p>



<a name="218585915"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218585915" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218585915">(Dec 02 2020 at 16:57)</a>:</h4>
<p>The visibility of the type's layout. :P</p>



<a name="218585934"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218585934" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218585934">(Dec 02 2020 at 16:58)</a>:</h4>
<p>This was the most appealing aspect of <code>Muckable</code>- it provided an actual source-level entity representing "the type's layout" that could be exposed or not-exposed.</p>



<a name="218586020"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586020" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586020">(Dec 02 2020 at 16:58)</a>:</h4>
<p>Like, without that then the sort of intrinsic I'm talking about would only be usable if all fields were primitives.</p>



<a name="218586056"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586056" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586056">(Dec 02 2020 at 16:58)</a>:</h4>
<p>(Or other structs in the same module where it bottoms out at primitives.)</p>



<a name="218586299"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586299" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586299">(Dec 02 2020 at 17:00)</a>:</h4>
<p>This doesn't sound like anything you can abstract over, even slightly. <span aria-label="slight frown" class="emoji emoji-1f641" role="img" title="slight frown">:slight_frown:</span></p>



<a name="218586434"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586434" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586434">(Dec 02 2020 at 17:01)</a>:</h4>
<p>Yeah see <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218582671">my acknowledgement of that detail</a> :/</p>



<a name="218586541"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586541" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586541">(Dec 02 2020 at 17:01)</a>:</h4>
<p>The point is, I think the abstraction needs to be separated out a bit more than it is with <code>Scope</code>, so it can match idioms with the rest of the language and not have weird pitfalls and holes.</p>



<a name="218586619"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586619" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586619">(Dec 02 2020 at 17:02)</a>:</h4>
<p>E.g. Muckable + a sound archetype system might meet that goal.</p>



<a name="218586950"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218586950" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218586950">(Dec 02 2020 at 17:04)</a>:</h4>
<p>IOW I want to separate the visibility of a field from the visibility of its offset and size, because today the first does not imply the second.</p>



<a name="218587343"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218587343" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218587343">(Dec 02 2020 at 17:06)</a>:</h4>
<p>Currently, if I can see a field, I can tell you its offset, size, and padding in <em>completely</em> safe code.</p>



<a name="218587881"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218587881" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218587881">(Dec 02 2020 at 17:09)</a>:</h4>
<p>Yeah but you're ignoring what we just discussed about <code>size_of</code>/<code>align_of</code>! You can of course find that information, but the "right" way to use that information is in a generic way that only assumes that it <em>exists</em> and nothing about its actual content. Once we start talking about transmutes, we shift focus from "does this field exist and have <em>some</em> offset/size/padding" to "does this field exist <em>at this particular</em> offset/size/padding."</p>



<a name="218588169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218588169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218588169">(Dec 02 2020 at 17:11)</a>:</h4>
<p>It's the difference between a bound like <code>T: Iterator</code> (this thing has a <code>next</code> method that returns <code>Option&lt;T::Item&gt;</code>) and <code>T: Iterator&lt;Item = i32&gt;</code> (this thing specifically gives me <code>i32</code>s).</p>



<a name="218588859"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218588859" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218588859">(Dec 02 2020 at 17:16)</a>:</h4>
<p>That's just not accurate. These intrinsics are used to assert that properties are upheld. For pointer bitpacking, I use <code>align_of</code> to enforce that I have sufficient unused bits in my pointer. Or that a struct is a <em>particular</em> size. These aren't considered misuses, as far as I'm aware.</p>
<p>Just because you <em>can</em> use a transmutability intrinsic in a way that depends on field offsets (just as you <em>can</em> use <code>as</code> casting to rely on field offsets) doesn't mean <em>all</em> uses of such an intrinsic must care about field offsets. <code>mem::zeroed()</code> is a prime example of this.</p>



<a name="218589031"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589031" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589031">(Dec 02 2020 at 17:17)</a>:</h4>
<p>I think your line-in-the-sand is this: "We must not provide an automatic, abstractable intrinsic for transmutation Safety™."</p>



<a name="218589092"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589092" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589092">(Dec 02 2020 at 17:18)</a>:</h4>
<p>Please, that's absurd.</p>



<a name="218589127"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589127" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589127">(Dec 02 2020 at 17:18)</a>:</h4>
<p>What is?</p>



<a name="218589130"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589130" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589130">(Dec 02 2020 at 17:18)</a>:</h4>
<p>Do you genuinely not understand what I'm trying to say? Or do you understand and just disagree?</p>



<a name="218589361"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589361" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589361">(Dec 02 2020 at 17:20)</a>:</h4>
<p>That's what I'm trying to figure out by stating what I <em>think</em> your line is. I <em>think</em> you're okay with an automatic intrinsic that <em>isn't</em> abstractable. And I think you're okay with something that's abstractable, but not fully automatic. </p>
<p>But you object to an intrinsic that's both automatic <em>and</em> abstractable.</p>



<a name="218589496"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589496" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589496">(Dec 02 2020 at 17:21)</a>:</h4>
<p>I have no opinion on abstractability or automatability per se, I don't understand why you would even bring those up. They're consequences of the combination of my <em>actual</em> objection and the particular design you've proposed.</p>



<a name="218589656"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218589656" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218589656">(Dec 02 2020 at 17:22)</a>:</h4>
<p>IOW if we can come up with a design that is both abstractable and automatic and <em>also</em> does not expose type layouts without an opt-in, I'd be absolutely thrilled.</p>



<a name="218590255"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218590255" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218590255">(Dec 02 2020 at 17:26)</a>:</h4>
<p>Type size, type alignment, field offset, field size, and field alignment are all <em>already</em> exposed in the sense that they're all safely observable. The only thing that <em>isn't</em> currently observable is bit validity.</p>



<a name="218590606"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218590606" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218590606">(Dec 02 2020 at 17:28)</a>:</h4>
<p>I bring up abstractibility and automatability because you've repeatedly suggested to remove either one of those aspects.</p>



<a name="218591287"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218591287" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218591287">(Dec 02 2020 at 17:33)</a>:</h4>
<ul>
<li>An intrinsic that requires the involved types to be fully instantiated simply cannot be abstracted over. This is the great limitation of <code>mem::transmute</code>. </li>
<li>A mechanism that requires special opt-in for making bit validity observable is, definitionally, not automatic.</li>
</ul>



<a name="218591410"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218591410" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218591410">(Dec 02 2020 at 17:34)</a>:</h4>
<p>Observability is too low a bar. I've tried to explain my position on that several times, do you at least understand the point I'm trying to make there?</p>



<a name="218591987"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218591987" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218591987">(Dec 02 2020 at 17:38)</a>:</h4>
<p>I do understand your point. I believe your conclusion is that "APIs that provide observability without stability shouldn't exist".</p>



<a name="218592401"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218592401" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218592401">(Dec 02 2020 at 17:41)</a>:</h4>
<p>Then why is it that you keep trying to use the existence of mem::size_of to convince me that such APIs are okay?</p>



<a name="218592688"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218592688" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218592688">(Dec 02 2020 at 17:43)</a>:</h4>
<p>I suggested those removals (in a thread about an "incremental approach!") not because I see them as an end goal, but because without them we can still do <em>some</em> transmutes without the problem of instability.</p>



<a name="218592874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218592874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218592874">(Dec 02 2020 at 17:44)</a>:</h4>
<p>I fully anticipate a more comprehensive solution that does allow abstracting over these properties, so long as the required properties are properly expressed in the type system.</p>



<a name="218592958"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218592958" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218592958">(Dec 02 2020 at 17:45)</a>:</h4>
<p>Like, my conclusion is still <em>way</em> more nuanced than "apis that provide observability without stability shouldn't exist."</p>



<a name="218593159"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593159" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593159">(Dec 02 2020 at 17:46)</a>:</h4>
<p>It's that we shouldn't <em>exploit</em> observability in unstable ways. <code>mem::size_of</code> gets a pass because it's been there since long before 1.0 without any alternative, but uses of it that rely on unstable aspects of a type do not get such a pass.</p>



<a name="218593216"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593216" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593216">(Dec 02 2020 at 17:47)</a>:</h4>
<p>You're proposing to 1) expand observability without stability 2) in a foundational API.</p>



<a name="218593531"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593531" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593531">(Dec 02 2020 at 17:49)</a>:</h4>
<p>(And that doesn't even touch on the fact that <code>Scope</code> is still deeply un-idiomatic. Type privacy is there to enforce that private types stay private, not as a building block for first-class visibility tokens. We already have first-class visibility tokens, they're called trait impls.)</p>



<a name="218593598"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593598" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593598">(Dec 02 2020 at 17:49)</a>:</h4>
<p>Yeah, I don't think I can convince you that such APIs are okay. However, I think the vast majority of Rust programmers find <code>align_of</code> and <code>size_of</code> to be totally unobjectionable. I think someone dropping into this chat would be alarmed by a lot of your messages. For instance, that the foundational API "punches a hole in safety and visibility". This is SUPER alarming — but you're using "safety" in an idiosyncratic way. Or, that the foundational API provides a slew of new, dangerous observational powers that don't exist today. It doesn't. </p>
<p>I agree with you that layout stability is a worthy challenge. I <em>disagree</em> that we need to solve it completely before providing a foundational API for arbitrary transmutations.</p>



<a name="218593760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593760">(Dec 02 2020 at 17:50)</a>:</h4>
<p>Well I'm not saying we need to solve it completely up front either. I'm saying we need to stop undermining our ability to solve it well in the future.</p>



<a name="218593873"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593873" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593873">(Dec 02 2020 at 17:51)</a>:</h4>
<p>I think solving stability is going to be a <em>long</em> process. I think we stand a better chance of getting it right if we first provide a foundational API, and then watch how the community builds stable abstractions over it.</p>



<a name="218593897"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593897" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593897">(Dec 02 2020 at 17:51)</a>:</h4>
<p>Let's pick a foundational API that doesn't punch a hole in visibility, then.</p>



<a name="218593932"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218593932" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218593932">(Dec 02 2020 at 17:51)</a>:</h4>
<p>Sigh. Stability. It punches a hole in <em>stability</em>. Not visibility.</p>



<a name="218594030"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594030" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594030">(Dec 02 2020 at 17:52)</a>:</h4>
<p>Visibility is how you control stability.</p>



<a name="218594249"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594249" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594249">(Dec 02 2020 at 17:54)</a>:</h4>
<p>I really don't appreciate being called "SUPER alarming" for pointing out that your proposal makes some aspects of types newly visible with no control over that visibility.</p>



<a name="218594299"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594299" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594299">(Dec 02 2020 at 17:54)</a>:</h4>
<p>I'll quit calling it a safety hole because that's kind of a weird fuzzy nuanced argument, but it is <em>absolutely</em> a visibility hole.</p>



<a name="218594328"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594328" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594328">(Dec 02 2020 at 17:55)</a>:</h4>
<p>It's not even totally "newly visible". <code>mem::zeroed</code> panics these days!</p>



<a name="218594390"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594390" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594390">(Dec 02 2020 at 17:55)</a>:</h4>
<p>Not based on any sort of trait bound, though.</p>



<a name="218594490"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594490" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594490">(Dec 02 2020 at 17:56)</a>:</h4>
<p>Panics in mem::zeroed are a last-ditch effort to make that API less error-prone by making the worst cases fail at runtime. That's not exactly something to aspire to.</p>



<a name="218594623"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594623" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594623">(Dec 02 2020 at 17:57)</a>:</h4>
<p>You have the relationship backwards, too. Stability dictates the set of changes you can make to an item. Visibility is one class of changes constrained by stability, but there are <em>tons</em>. And not all are in-language either. If you want the alignment of your type to be stable, you document it. If you want <code>#[repr(C)]</code> to be stable, you document it.</p>



<a name="218594688"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218594688" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218594688">(Dec 02 2020 at 17:57)</a>:</h4>
<p>I thought the point of safe transmute was to bring those aspects into the language.....?</p>



<a name="218595066"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595066" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595066">(Dec 02 2020 at 18:00)</a>:</h4>
<p>No, not really. It's in the name: to make transmutations safe (in the usual understanding of the term). Yes, I want to solve layout stability too, but that's complimentary, not core, to our charter.</p>



<a name="218595472"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595472" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595472">(Dec 02 2020 at 18:03)</a>:</h4>
<p>Well, if you can chop stability out of the charter then I can chop abstraction out of the charter. Stability and abstraction go hand-in-hand, separating them is, again, asking for trouble.</p>



<a name="218595556"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595556" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595556">(Dec 02 2020 at 18:03)</a>:</h4>
<p>A safe transmute that only works on fully-visible types is still safe, and you can still build some abstractions on it.</p>



<a name="218595602"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595602" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595602">(Dec 02 2020 at 18:03)</a>:</h4>
<p>Why not start there and then expand its capabilities as we solve layout stability?</p>



<a name="218595677"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595677" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595677">(Dec 02 2020 at 18:04)</a>:</h4>
<p>Can determine fully-visible types? The original purpose of <code>Scope</code> was to solve the pub-in-priv hole.</p>



<a name="218595713"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595713" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595713">(Dec 02 2020 at 18:04)</a>:</h4>
<p>^Yes, but only by nixing abstraction.</p>



<a name="218595715"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595715" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595715">(Dec 02 2020 at 18:04)</a>:</h4>
<p>Fully-visible as in, defined in the same module where visibility is irrelevant.</p>



<a name="218595733"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595733" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595733">(Dec 02 2020 at 18:04)</a>:</h4>
<p>e.g., as in how <code>mem::transmute</code> can't be called on generic types</p>



<a name="218595874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595874">(Dec 02 2020 at 18:06)</a>:</h4>
<p>Well, like I described in the "golden standard" thread, you certainly <em>can</em> still abstract over mem::transmute. That's how trait impls work- they bottom out at non-generic types, where you <em>can</em> do things that require full visibility.</p>



<a name="218595959"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218595959" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218595959">(Dec 02 2020 at 18:06)</a>:</h4>
<p>You just can't use mem::transmute-alikes directly on generic types- you have to go through a trait.</p>



<a name="218596040"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596040" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596040">(Dec 02 2020 at 18:07)</a>:</h4>
<p>Another useful term here is parametricity.</p>



<a name="218596157"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596157" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596157">(Dec 02 2020 at 18:08)</a>:</h4>
<p>I don't think that's true. If you try to use <code>mem::transmute</code>, you can't do so on generic types no matter where they occur. If you use it in a trait, it needs to occur in <em>individual</em> trait impls.</p>



<a name="218596178"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596178" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596178">(Dec 02 2020 at 18:08)</a>:</h4>
<p>Yes, that's exactly what I said...</p>



<a name="218596202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596202">(Dec 02 2020 at 18:08)</a>:</h4>
<p>...so you're not really abstracting over anything.</p>



<a name="218596237"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596237" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596237">(Dec 02 2020 at 18:08)</a>:</h4>
<p>Of course you are. You're abstracting over all the individual impls that call mem::transmute.</p>



<a name="218596318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596318">(Dec 02 2020 at 18:09)</a>:</h4>
<p>You've got the idea of "mem::transmute but it works on generic types" so deeply embedded in your idea of how this should work that you're dismissing alternatives.</p>



<a name="218596376"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596376" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596376">(Dec 02 2020 at 18:09)</a>:</h4>
<p>So this would in practice be a <code>mem::transmute</code> that is safe because it tests for visibility at the use site?</p>



<a name="218596495"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596495" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596495">(Dec 02 2020 at 18:10)</a>:</h4>
<p>Well that's one possibility.</p>



<a name="218596541"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596541" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596541">(Dec 02 2020 at 18:10)</a>:</h4>
<p><span class="user-mention silent" data-user-id="117495">rpjohnst</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218595472">said</a>:</p>
<blockquote>
<p>Well, if you can chop stability out of the charter then I can chop abstraction out of the charter. Stability and abstraction go hand-in-hand, separating them is, again, asking for trouble.</p>
</blockquote>
<p>I'm not chopping anything of our charter. We're here to make transmutations safe. We have a design that makes transmutations safe. We even have a complementary design that makes <em>some</em> transmutations stable, too!</p>
<p>Nixing abstraction is artificially pruning the set of transmutations we will make safe.</p>



<a name="218596797"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596797" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596797">(Dec 02 2020 at 18:12)</a>:</h4>
<p>Generally our disagreement seems to be over where safety is checked. You propose to check it at any use site, by tying layout visibility to field visibility. I would rather keep layout private by default, and then use established idioms to (partially) expose it.</p>



<a name="218596834"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596834" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596834">(Dec 02 2020 at 18:13)</a>:</h4>
<p>Layout isn't private.</p>



<a name="218596868"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596868" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596868">(Dec 02 2020 at 18:13)</a>:</h4>
<p>(I.e., I propose for safety to be checked at the site that makes (an aspect of) layout visible.)</p>



<a name="218596913"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596913" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596913">(Dec 02 2020 at 18:13)</a>:</h4>
<p>Well that's what we've been discussing all morning! Layout is partially <em>observable</em> today but only in limited ways, and even those ways are arguably incorrect for some use cases.</p>



<a name="218596982"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218596982" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218596982">(Dec 02 2020 at 18:14)</a>:</h4>
<p>It's not limited at all! <em>Every</em> aspect of layout <em>except</em> bit validity is safely observable.</p>



<a name="218597019"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597019" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597019">(Dec 02 2020 at 18:14)</a>:</h4>
<p>Some aspects of layout still <em>are</em> private in the sense that changing them is considered non-breaking, despite those changes breaking some ill-advised constructs.</p>



<a name="218597045"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597045" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597045">(Dec 02 2020 at 18:14)</a>:</h4>
<p>You keep conflating observability and visibility and I would rather you not. ;)</p>



<a name="218597108"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597108" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597108">(Dec 02 2020 at 18:15)</a>:</h4>
<p>You keep conflating visibility with stability! We have an accepted term for the kind of thing you are describing. It's stability. Not visibility.</p>



<a name="218597137"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597137" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597137">(Dec 02 2020 at 18:15)</a>:</h4>
<p>Ugh, whatever, forget the terminology, it's irrelevant to my point!</p>



<a name="218597170"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597170" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597170">(Dec 02 2020 at 18:16)</a>:</h4>
<p>My point is, I don't want people writing generic code that will stop compiling when I make changes that used to be non-breaking!</p>



<a name="218597349"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597349" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597349">(Dec 02 2020 at 18:17)</a>:</h4>
<p>(And simply declaring by fiat that those changes are still non-breaking doesn't really solve anything.)</p>



<a name="218597417"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597417" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597417">(Dec 02 2020 at 18:17)</a>:</h4>
<p>Just to prod this a bit, would you be ok with something like a <code>SizeEq</code> or <code>AlignEq</code> trait (something there's been interest in)? You can already assert on the size of an object, and this would just fail with a compile time error (the same why <code>mem::transmute</code> errors if size changes even thought that breaks code)?</p>



<a name="218597592"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597592" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597592">(Dec 02 2020 at 18:19)</a>:</h4>
<p>Yes, that would be wonderful (as long as it's opt-in on the part of the type author).</p>



<a name="218597601"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597601" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597601">(Dec 02 2020 at 18:19)</a>:</h4>
<p>That's exactly the sort of thing I'm pushing for.</p>



<a name="218597678"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597678" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597678">(Dec 02 2020 at 18:19)</a>:</h4>
<p><span class="user-mention" data-user-id="303115">@Quy Nguyen</span> do you mean an automatic <code>AlignEq</code> trait?</p>



<a name="218597685"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597685" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597685">(Dec 02 2020 at 18:19)</a>:</h4>
<p>I'd love to be able to declare in the trait system that my type is always going to be pointer-sized, for example.</p>



<a name="218597803"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597803" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597803">(Dec 02 2020 at 18:20)</a>:</h4>
<p>Yes, I had bad wording :( An automatic AlignEq trait.</p>



<a name="218597933"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218597933" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218597933">(Dec 02 2020 at 18:21)</a>:</h4>
<p>I'd even consider being okay with it being an auto trait, if there were some way to opt <em>out</em> of it through <code>PhantomData</code> or similar. It would certainly be a pain to have to declare <code>Send</code> and <code>Sync</code> all the time, even though changing whether they're impled is considered breaking.</p>



<a name="218598169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598169">(Dec 02 2020 at 18:23)</a>:</h4>
<p>...so would you be okay with an <code>UnstableTransmuteFrom</code> trait you can opt out of?</p>



<a name="218598231"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598231" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598231">(Dec 02 2020 at 18:23)</a>:</h4>
<p>That one's much more comprehensive so I'd have to think about it. And I'd still object to the <code>Scope</code> mechanism out of sheer weirdness and complexity.</p>



<a name="218598527"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598527" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598527">(Dec 02 2020 at 18:25)</a>:</h4>
<p>I do wonder we couldn't just start with a sound archetype system, where the type author impls TransmutableFrom/Into (through a derive if they want full layout stability), the compiler checks that the impl is valid (like Copy), and then mem::safe_transmute uses those traits.</p>



<a name="218598655"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598655" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598655">(Dec 02 2020 at 18:26)</a>:</h4>
<p>I encourage you to take a stab at making archetypes sound.</p>



<a name="218598756"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598756" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598756">(Dec 02 2020 at 18:27)</a>:</h4>
<p>Though that system got a <em>lot</em> of pushback just for its complexity. (Which is partly why I'm of the mind that there <em>isn't</em> a one-size fits all stability system, but rather different systems tuned to different use-cases.)</p>



<a name="218598795"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598795" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598795">(Dec 02 2020 at 18:27)</a>:</h4>
<p>Well, there <em>was</em> a lot of complexity there that I am imagining doing away with.</p>



<a name="218598956"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598956" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598956">(Dec 02 2020 at 18:28)</a>:</h4>
<p>For instance I would probably just leave out <em>all</em> the Neglect options. :P</p>



<a name="218598985"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218598985" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218598985">(Dec 02 2020 at 18:28)</a>:</h4>
<p>And of course there would be no need for <code>Scope</code>.</p>



<a name="218599058"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599058" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599058">(Dec 02 2020 at 18:29)</a>:</h4>
<p>Well. No, Scope is pretty essential for the use-cases I'm interested in. Namely: purely local analysis of transmutation safety.</p>



<a name="218599095"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599095" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599095">(Dec 02 2020 at 18:29)</a>:</h4>
<blockquote>
<p>I'd love to be able to declare in the trait system that my type is always going to be pointer-sized, for example.</p>
</blockquote>
<p>Honestly I prefer a direct static assert on size to whatever it would probably look like in the trait system. It's awkward to have to do stuff like:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">assert_send</span><span class="o">&lt;</span><span class="n">T</span>: <span class="nb">Send</span><span class="o">&gt;</span><span class="p">()</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>
<span class="k">const</span><span class="w"> </span><span class="n">_</span>: <span class="p">()</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">assert_send</span>::<span class="o">&lt;</span><span class="n">MyType</span><span class="o">&gt;</span><span class="p">();</span><span class="w"></span>
</code></pre></div>
<hr>
<p>This is no longer really what you're talking about, but as a data point on alignment stability, I've seen code that had <code>type PhantomAligned&lt;T&gt; = [T; 0];</code> before.</p>



<a name="218599217"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599217" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599217">(Dec 02 2020 at 18:30)</a>:</h4>
<p>^This is moreso how I'm envisioning "general" stability too.</p>



<a name="218599279"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599279" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599279">(Dec 02 2020 at 18:30)</a>:</h4>
<p>I'm not sure "purely local" is really compatible with stability.</p>



<a name="218599286"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599286" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599286">(Dec 02 2020 at 18:30)</a>:</h4>
<p><span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span> have you played with the static assertions crate? It's phenomenal.</p>



<a name="218599292"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599292" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599292">(Dec 02 2020 at 18:30)</a>:</h4>
<p>If it means what I think it means.</p>



<a name="218599304"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599304" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599304">(Dec 02 2020 at 18:30)</a>:</h4>
<p><span class="user-mention" data-user-id="117495">@rpjohnst</span> It's not compatible.</p>



<a name="218599335"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599335" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599335">(Dec 02 2020 at 18:31)</a>:</h4>
<p>Yes, I have. I'm good friends with the author too.</p>



<a name="218599359"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599359" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599359">(Dec 02 2020 at 18:31)</a>:</h4>
<p>Perhaps we ought to dig more into that use case, then.</p>



<a name="218599392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599392">(Dec 02 2020 at 18:31)</a>:</h4>
<p>I'm hoping we can arrive at something that's sufficiently signposted that you'd be satisfied. E.g., <code>UnstableTransmuteFrom</code> or <code>ExtraScaryUnstableTransmuteFrom</code>.</p>



<a name="218599485"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599485" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599485">(Dec 02 2020 at 18:32)</a>:</h4>
<p>No amount of signposting will satisfy me. Signposting is exactly my complaint.</p>



<a name="218599577"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599577" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599577">(Dec 02 2020 at 18:32)</a>:</h4>
<p>A type's author ought to have control over whether their type is transmutable, independent of field visibility.</p>



<a name="218599580"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599580" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599580">(Dec 02 2020 at 18:32)</a>:</h4>
<p>Then I think we're simply at an impasse.</p>



<a name="218599635"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599635" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599635">(Dec 02 2020 at 18:33)</a>:</h4>
<p>Thus:</p>
<blockquote>
<p>Perhaps we ought to dig more into that use case, then.</p>
</blockquote>



<a name="218599679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599679">(Dec 02 2020 at 18:33)</a>:</h4>
<p>What, exactly, would type author control take away from you?</p>



<a name="218599778"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599778" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599778">(Dec 02 2020 at 18:34)</a>:</h4>
<p>I cannot generate layout stability impls on the fly.</p>



<a name="218599809"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218599809" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218599809">(Dec 02 2020 at 18:34)</a>:</h4>
<p>That's up to the authors of those types.</p>



<a name="218600002"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600002" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600002">(Dec 02 2020 at 18:36)</a>:</h4>
<p>And even if I could, that wouldn't respect field visibility, which is essential to safety.</p>



<a name="218600056"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600056" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600056">(Dec 02 2020 at 18:36)</a>:</h4>
<p><span class="user-mention" data-user-id="117495">@rpjohnst</span> if you can convert to the type that's basically equivalent to having public writable fields. if you can convert from it, it's equivalent to having public readable fields. No?</p>



<a name="218600246"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600246" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600246">(Dec 02 2020 at 18:38)</a>:</h4>
<p>ehh maybe i'm covering well-explored ground. i don't really want to wade into this if I'm just going to cause repetition of earlier discussion that's already happened.</p>



<a name="218600264"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600264" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600264">(Dec 02 2020 at 18:38)</a>:</h4>
<p>What I'm asking is, what sort of use cases are blocked by type author control? We need to consider whether those use cases are actually worth addressing, before we toss stability out the window.</p>



<a name="218600441"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600441" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600441">(Dec 02 2020 at 18:39)</a>:</h4>
<p>Addressing my use-cases is pretty much my motivation for working on solving safe transmute. <span aria-label="slight frown" class="emoji emoji-1f641" role="img" title="slight frown">:slight_frown:</span></p>



<a name="218600449"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600449" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600449">(Dec 02 2020 at 18:39)</a>:</h4>
<p>A type author opt-in (or opt-out, I suppose) to (perhaps partial) transmutability is how they would mark those aspect(s) of their type's layout as <del>public</del> stable, rather than merely observable.</p>



<a name="218600480"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600480" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600480">(Dec 02 2020 at 18:39)</a>:</h4>
<p>I should also say, we need to consider whether they're addressable in other ways!</p>



<a name="218600862"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218600862" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218600862">(Dec 02 2020 at 18:42)</a>:</h4>
<p>Like, if your use cases are "let me transmute types I don't own in ways they haven't opted into (or would like to have opted out of), which may break when their authors make formerly-non-breaking changes" then that's really not something we should be addressing. But if that's just an XY-problem and you would be able to accomplish what you want with the type author's participation in some way, there's probably a better solution.</p>



<a name="218601425"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218601425" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218601425">(Dec 02 2020 at 18:46)</a>:</h4>
<p>There's a <em>ton</em> of existing unsafe code out there that relies only on documented layout guarantees for its safety. The participation of the type's author <em>is</em> the documented stability guarantees. Or, often, the person doing the transmutation because it's within the same SemVer universe (though not necessarily the same module or even crate).</p>
<p>I'm interested in making this code safer <em>without</em> necessitating non-local changes (e.g., rewriting type internals, redesigning existing abstractions, etc).</p>



<a name="218601582"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218601582" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218601582">(Dec 02 2020 at 18:48)</a>:</h4>
<p>I think we need to consider "the type author converts from a doc comment to some kind of trait impl" as an acceptable change to require.</p>



<a name="218601713"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218601713" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218601713">(Dec 02 2020 at 18:48)</a>:</h4>
<p>Otherwise we're basically just saying "hey I know a bunch of types don't implement Copy, but they could implement it, and I don't want to wait around for new crate versions, so let's just add a new UnstableCopy trait for people to use instead."</p>



<a name="218601842"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218601842" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218601842">(Dec 02 2020 at 18:50)</a>:</h4>
<p>I also think it would be totally acceptable for the initial version of safe transmute not to address every use case! If some crates have to stick to unsafe transmute until we come up with a way for type authors to stablize the properties they depend on, that's okay.</p>



<a name="218601951"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218601951" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218601951">(Dec 02 2020 at 18:50)</a>:</h4>
<p>If a type could implement Copy but you have visibility into its fields, you <em>can</em>, practically speaking, copy it.</p>



<a name="218602014"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602014" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602014">(Dec 02 2020 at 18:51)</a>:</h4>
<p>Yes, but that still doesn't mean we should add UnstableCopy for types like that. It means those type authors should consider implementing Copy.</p>



<a name="218602066"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602066" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602066">(Dec 02 2020 at 18:51)</a>:</h4>
<p>Which they might not want to do, because they don't want to make Copy part of their semver guarantee.</p>



<a name="218602218"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602218" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602218">(Dec 02 2020 at 18:52)</a>:</h4>
<p>If they dont' want to make Copy part of their semver guarantee then that's a pretty strong argument <em>against</em> UnstableCopy, no?</p>



<a name="218602229"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602229" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602229">(Dec 02 2020 at 18:52)</a>:</h4>
<p>I think that's a private impl question though.</p>



<a name="218602478"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602478" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602478">(Dec 02 2020 at 18:54)</a>:</h4>
<p>That is to say, does any of this (type author converts doc comments to trait impls, not all use cases can use safe transmute on day 1) actually <em>block</em> your use cases? Or are we just arguing over the UnstableCopy thing?</p>



<a name="218602505"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602505" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602505">(Dec 02 2020 at 18:54)</a>:</h4>
<p><span class="user-mention silent" data-user-id="303115">Quy Nguyen</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218602229">said</a>:</p>
<blockquote>
<p>I think that's a private impl question though.</p>
</blockquote>
<p>^Kinda, yeah. And that's why <code>UnstableTransmuteFrom</code> is scope-aware.</p>



<a name="218602748"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602748" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602748">(Dec 02 2020 at 18:56)</a>:</h4>
<p>If we had private impls, would <code>InvariantFree</code> + derives work for your use cases?</p>



<a name="218602870"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218602870" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218602870">(Dec 02 2020 at 18:57)</a>:</h4>
<p>No, because a local transformation at the point of transmutation can't just generate impls for non-local types. Not in any safe sense, at least.</p>



<a name="218603127"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218603127" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218603127">(Dec 02 2020 at 18:59)</a>:</h4>
<p>Can you explain?</p>



<a name="218609859"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218609859" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218609859">(Dec 02 2020 at 19:53)</a>:</h4>
<p>Sure. <a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Encapsulation.20Redundancy.20Risks/near/218330313">Check out this topic</a>, but the gist is: field visibility is what matters when determining whether its safe to fiddle with a field.</p>
<p>In contrast, type visibility is what matters when determining the visibility of an impl. So, a trait that denotes "treat all my fields as recursively pub" will have the same visibility of the type its implemented on.</p>



<a name="218610338"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218610338" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218610338">(Dec 02 2020 at 19:57)</a>:</h4>
<p>Let's say I have a safe <code>transmute!</code> macro with which I can replace occurences of <code>mem::transmute</code> and <code>transmute_copy</code>, and union accesses, etc. In the foundational approach, this boils down to:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="kr">macro</span><span class="w"> </span><span class="n">transmute</span><span class="p">(</span><span class="cp">$expr</span>: <span class="nc">expr</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="p">{</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Here</span><span class="p">;</span><span class="w"> </span><span class="n">UnstableTransmuteFrom</span>::<span class="o">&lt;</span><span class="n">_</span><span class="p">,</span><span class="w"> </span><span class="n">Here</span><span class="o">&gt;</span>::<span class="n">transmute_from</span><span class="p">(</span><span class="cp">$expr</span><span class="p">)</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>This doesn't let me muck with any fields I didn't already have visibility on at the invocation site.</p>
<p>In a scope-unaware approach where a trait (e.g., <code>Muckable</code>) is used, it'd look like this:</p>



<a name="218610362"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218610362" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218610362">(Dec 02 2020 at 19:57)</a>:</h4>
<p>uh, well actually, I don't even know how to write it.</p>



<a name="218610527"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218610527" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218610527">(Dec 02 2020 at 19:58)</a>:</h4>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="kr">macro</span><span class="w"> </span><span class="n">transmute</span><span class="p">(</span><span class="cp">$expr</span>: <span class="nc">expr</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="k">impl</span><span class="w"> </span><span class="n">Muckable</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">SRC_TYPE</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>
<span class="w">        </span><span class="k">impl</span><span class="w"> </span><span class="n">Muckable</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">DST_TYPE</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>
<span class="w">        </span><span class="n">TransmuteFrom</span>::<span class="o">&lt;</span><span class="n">_</span><span class="o">&gt;</span>::<span class="n">transmute_from</span><span class="p">(</span><span class="cp">$expr</span><span class="p">)</span><span class="w"></span>
<span class="w">    </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>(I can't use the <code>_</code> trick to infer the source and destination types for the purposes of implementing <code>Muckable</code>. Not sure what the workaround here is....)</p>



<a name="218611131"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218611131" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218611131">(Dec 02 2020 at 20:03)</a>:</h4>
<p>Even if I could name the src and dst types for the purposes of impl'ing <code>Muckable</code>, other issues arise.</p>
<p>First, I can't necessarily implement traits for these types. If I've broken up my network stack code into lots of sub-crates that are all part of the same semver universe, I can't implement <code>Muckable</code> for any type that aren't defined in the same sub-crate, and thus this macro is unworkable.</p>



<a name="218611289"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218611289" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218611289">(Dec 02 2020 at 20:04)</a>:</h4>
<p>Second, even when I can, it's a <em>terrible</em> idea for me to do so for types outside the same module. Just because I have visibility on a type, <em>doesn't</em> mean I have visibility onto its fields. A macro that clobbers the visibility of fields is a safety hazard.</p>



<a name="218611532"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218611532" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218611532">(Dec 02 2020 at 20:06)</a>:</h4>
<p>Ultimately, the decision of whether fields are visible is one made at the definition site of a type. I can't judge whether fiddling with a field is safe without first confirming that I <em>can</em> fiddle with the field.</p>



<a name="218613745"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218613745" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218613745">(Dec 02 2020 at 20:22)</a>:</h4>
<p>Muckable would be derived or implemented at the definition site right?</p>



<a name="218614025"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614025" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614025">(Dec 02 2020 at 20:23)</a>:</h4>
<p>So, that all still feels like you're just trying to avoid having type authors participate. Like, providing <em>just</em> a safe transmute that lets you do anything that's valid value-wise doesn't capture stability, obviously, but I still don't see any sort of justification for that beyond "it's too hard to design a full layout stability system up front" or "it's too annoying/invasive to wait for type authors to opt in."</p>



<a name="218614049"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614049" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614049">(Dec 02 2020 at 20:23)</a>:</h4>
<p>It would have to be. If the field visibility is anything less than all-pub, then the type would need to be refactored.</p>



<a name="218614135"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614135" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614135">(Dec 02 2020 at 20:24)</a>:</h4>
<p><span class="user-mention" data-user-id="117495">@rpjohnst</span> All of this can happen within the same semver universe, e.g., as in subcrates, or even within the same crate but across different modules.</p>



<a name="218614160"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614160" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614160">(Dec 02 2020 at 20:24)</a>:</h4>
<p>But you aren't <em>enforcing</em> that it happens within the same semver universe- it can also happen outside it.</p>



<a name="218614295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614295">(Dec 02 2020 at 20:25)</a>:</h4>
<p>Yes, you understand correctly. I'm not convinced that we must absolutely <strong>not</strong> provide bit validity observability without stability.</p>



<a name="218614384"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614384" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614384">(Dec 02 2020 at 20:26)</a>:</h4>
<p>I think we're at an impasse, here.</p>



<a name="218614407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614407">(Dec 02 2020 at 20:26)</a>:</h4>
<p>With private impls, you could make it <code>pub(crate)</code> or <code>pub(super)</code> or whatever you need.</p>



<a name="218614416"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614416" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614416">(Dec 02 2020 at 20:26)</a>:</h4>
<p>Well I'm not trying to convince you of anything just yet, I'm trying to understand your use cases, as I asked here: <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218602478">https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218602478</a></p>



<a name="218614545"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614545" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614545">(Dec 02 2020 at 20:27)</a>:</h4>
<p><span class="user-mention silent" data-user-id="303115">Quy Nguyen</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218614407">said</a>:</p>
<blockquote>
<p>With private impls, you could make it <code>pub(crate)</code> or <code>pub(super)</code> or whatever you need.</p>
</blockquote>
<p>Those impls <em>still</em> need to be written at type definition sites. You can't soundly generate those impls at transmutation sites.</p>



<a name="218614684"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614684" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614684">(Dec 02 2020 at 20:28)</a>:</h4>
<p>Anyways, we still end up with two competing indicators of whether you can fiddle with a field. <a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Encapsulation.20Redundancy.20Risks/near/218330313">I think this is asking for trouble.</a></p>



<a name="218614881"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614881" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614881">(Dec 02 2020 at 20:30)</a>:</h4>
<p>That sounds like something that should be addressed by having the compiler check that you're allowed to impl Muckable.</p>



<a name="218614908"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218614908" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218614908">(Dec 02 2020 at 20:30)</a>:</h4>
<p><span class="user-mention" data-user-id="303115">@Quy Nguyen</span> Rust doesn't have a <code>pub(crate) impl</code> syntax, and will not have it in the foreseeable future. It <em>does</em> have a notion of impl privacy those, and that's what <code>UnstableTransmuteFrom</code> takes advantage of with its <code>Scope</code> parameter. It automatically respects the visibility of your fields.</p>



<a name="218617681"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218617681" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218617681">(Dec 02 2020 at 20:50)</a>:</h4>
<p>Forget what I said about private impls for now, I didn't have the axioms right in my head. If <code>Muckable</code> was exactly like <code>Copy</code> (usage-wise) and had no field stability gurantees, would your only compliant be that type authors have to manually derive it?</p>



<a name="218618860"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218618860" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218618860">(Dec 02 2020 at 21:00)</a>:</h4>
<p>That would resolve the issue of <a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Language-Level.20Layout.20Instability/near/218336402">language-level layout (in)stability</a> (i.e., <code>Muckable</code> is currently really just tuned for <code>repr(C)</code> types). But:</p>
<ul>
<li><a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Encapsulation.20Redundancy.20Risks/near/218330313">you still end up with two competing indicators of whether a field can be fiddled with</a></li>
<li><a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Partial.20Visibility/near/218478354">partial visibility is awkward, at best</a> (but an archetype-based stability system might do somewhat better here, if someone can figure out how to make it sound)</li>
<li><a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20No.20Quick.20Answers/near/218332628">you still can't purely-locally analyze the safety of transmutations</a></li>
<li><a href="#narrow/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Newtype.20Workaround.20Ergonomics/near/218320527">the partial-workaround of newtyping has steep ergonomic drawbacks, and it might not be worth trying to update unsafe code that already just works</a></li>
<li>we'd then need an additional stability system <em>besides</em> <code>Muckable</code> to opt-in to field ordering semver stability. the existence of a system that let one observe transmutability <em>without</em> providing adequate semver opt-ins is precisely what rpjohnst's is worried about</li>
</ul>



<a name="218645185"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218645185" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218645185">(Dec 03 2020 at 01:51)</a>:</h4>
<p><span class="user-mention" data-user-id="117495">@rpjohnst</span> FWIW I have definitely written the kind of code you wish didn't exist. A lot of my use cases for safe-transmute are when I want to <em>opt out</em> of visibility/stability promises made by an upstream crate, by taking their struct, transmuting it to one of mine, and then mucking with fields. Is this unsafe? Yes. The definition of satefy in rust includes invariants at module boundaries, so visibility override is unsafe. However rust can still assist in checking that the layout hasn't changed since I wrote the code. Currently I have to opt out of <em>memory safety</em> in this operation as well, which I would like to avoid. <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> 's proposal allows for this use case with the <code>NeglectStability</code> / <code>NeglectVisibility</code> options but you seem to want to block this.</p>
<p>You can reasonably ask why I need to do this. It mostly came up while trying to determine how much memory I have allocated, because that involves the internal details of a lot of crates I don't control, and I have no intention to modify them to support my use case.</p>



<a name="218645732"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218645732" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218645732">(Dec 03 2020 at 02:00)</a>:</h4>
<p>(Actually, this is arguably a misuse of transmute in the first place, in the sense that what is needed, visibility override, need not even involve memory unsafe operations but this is brought into the game because there is no way to override visibility on a field directly. So taking a hard stance on visibility protection actually makes UB-in-practice easier, which seems like a bad situation.)</p>



<a name="218651569"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218651569" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218651569">(Dec 03 2020 at 04:02)</a>:</h4>
<p>Yeah transmute is not a great solution here. Can you clarify whether this memory allocation measurement is a one-off debugging technique, or a permanent part of your program? If it's the former you may be able to use cargo patching without much trouble; if the latter you probably want allocator instrumentation.</p>



<a name="218653806"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218653806" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218653806">(Dec 03 2020 at 04:53)</a>:</h4>
<p>I can't patch std, that sounds like a nightmare</p>



<a name="218653863"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218653863" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218653863">(Dec 03 2020 at 04:54)</a>:</h4>
<p>it's mostly the former, although I want to test memory usage in some reasonably realistic scenarios so it can't differ too much from the production version</p>



<a name="218755094"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218755094" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218755094">(Dec 03 2020 at 21:11)</a>:</h4>
<p><span class="user-mention silent" data-user-id="209168">Thom Chiovoloni</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218253083">said</a>:</p>
<blockquote>
<p>I think it only working for public types would be unfortunate. That's an issue I always had with the bytemuck design (<code>ref_cast</code> has the same issue). <code>Scope</code> solves that problem in a way that seems explainable relatively simply, I wasn't really aware of what it did before <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218239871">this</a>, and that doesn't seem that bad for a low level building-block that a higher level api can be built on top of.</p>
</blockquote>
<p>Seconding this! The <code>Scope</code> parameter seems pretty explainable, particularly compared to all the <em>other</em> transmutation rules.</p>
<p>I spend a lot of time building abstractions over transmutations, and the foundational API seems like a <em>really</em> useful building block.</p>



<a name="218799710"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218799710" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218799710">(Dec 04 2020 at 07:07)</a>:</h4>
<p>I do think the central issue here is whether an privacy-scoped impl for a trait is the general idea for what you're arguing against, or whether you're against the Scope parameter specifically.</p>
<p>I actually don't remember what your main points are anymore, but I'll address some I've thought about.</p>
<p>Usability in a generic context:<br>
<code>mem::transmute</code> is not usable generically yes, but with improvements in const-eval/generics, I've seen a prototype that is.</p>
<p>Stability:<br>
The ability to introspect private fields is prohibited. Unsafe code can already cause breakage with <code>mem::transmute</code>, as well as <code>size_of</code> (but that is arguably special), and I'd argue that breaking something at compile time is miles better than causing hidden UB by merely updating.</p>
<p>Complexity:<br>
I do think this API is a lot less complex than many other solutions, simply because the concepts are expressed in the same Rust constructs people already use to express those concepts!</p>
<p>I think the final thing to just note here is that everything here <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218618860">https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218618860</a> is a use case for <code>Scope</code>- all organized into a single post</p>



<a name="218860315"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218860315" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218860315">(Dec 04 2020 at 16:59)</a>:</h4>
<p>I would summarize my my point as: we ought to preserve <em>modularity</em> (in the ML sense) as much as possible. This means type authors must be able to hide implementation details like the order of fields and other things that are currently non-breaking to change.</p>
<p>This means (applying the above to your points):</p>
<ul>
<li>I have no problem with generic safe transmute per se, only with the impls it would use being controlled entirely by existing field visibility. I.e. I disagree with Jack's assertion about "two competing indicators"- I <em>want</em> those things to be indicated separately, and I <em>don't</em> want purely-local analysis.</li>
<li>I have no problem with turning UB into compile errors either, I just want <em>even more</em> compile errors. Jack seems to think this will just lead people back to UB because the alternative of type authors opting in would be too onerous, though tbf he hasn't given me a straight answer here so I could be misinterpreting him. (And of course I see that opt-in, or at least opt-out, as crucial.)</li>
<li>My complaints about complexity are secondary, though I disagree that anyone is already using a <code>Scope</code>-like mechanism anywhere. I would also note that we have a large example of a language that avoids adding new language features when things can be done in a library - C++ - and it often just makes a big mess (e.g. <code>std::variant</code>/<code>std::visit</code>).</li>
</ul>
<p>(The linked post is more about the downsides of Muckable, which I also don't disagree with, than it is about the upsides of Scope. Personally I would rather we went with neither and instead came up with a system where external transmute call sites could <em>just</em> rely on a normal trait impl without Scope, as that solves the semver problem <em>and</em> happens to mean that we don't even need to decide whether Scope or any other form of private impls is explainable enough.)</p>



<a name="218887956"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218887956" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218887956">(Dec 04 2020 at 20:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="117495">rpjohnst</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Incremental.20Approach/near/218860315">said</a>:</p>
<blockquote>
<p>The linked post is more about the downsides of Muckable, which I also don't disagree with, than it is about the upsides of Scope. Personally I would rather we went with neither and instead came up with a system where external transmute call sites could just rely on a normal trait impl without Scope,</p>
</blockquote>
<p>Can you elaborate? The <code>Muckable</code> I asked about there would be just a normal trait impl that asserts that the type contains no further invariants beyond type-level ones.</p>



<a name="218893871"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218893871" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218893871">(Dec 04 2020 at 21:33)</a>:</h4>
<p>Right- Muckable on its own does satisfy "just rely on a normal trait impl without Scope," what I'm getting at is that Muckable is too limiting to be a general solution. One possibility to resolve that problem is some kind of semver-ignoring foundational API that we can build things on, but I would rather we skip that and come up with something that shares Muckable's "just a normal trait impl" property but also supports things like partial visibility.</p>



<a name="218935674"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218935674" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218935674">(Dec 05 2020 at 13:41)</a>:</h4>
<p><span class="user-mention" data-user-id="271719">@Mario Carneiro</span> </p>
<blockquote>
<p>Actually, this is arguably a misuse of transmute in the first place, in the sense that what is needed, visibility override, need not even involve memory unsafe operations</p>
</blockquote>
<p>visibility override is effectively memory-unsafe. e.g. if you override visibility of <code>Vec</code> and mutate its <code>capacity</code> field, that leads to memory unafety. I don't think you can entirely separate these concerns.</p>



<a name="218935689"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218935689" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218935689">(Dec 05 2020 at 13:41)</a>:</h4>
<p>That's true; this is what I meant by visibility override is unsafe</p>



<a name="218935733"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218935733" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218935733">(Dec 05 2020 at 13:42)</a>:</h4>
<p>I mean that rust can defend against the most immediate kind of UB</p>



<a name="218935737"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218935737" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218935737">(Dec 05 2020 at 13:42)</a>:</h4>
<p>it's still unsafe but it's not insta-UB</p>



<a name="218935815"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218935815" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218935815">(Dec 05 2020 at 13:45)</a>:</h4>
<p>put another way, it takes it down a notch from double-plus-unsafe that you see in the docs on <code>transmute</code> to regular unsafe</p>



<a name="218936039"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218936039" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218936039">(Dec 05 2020 at 13:51)</a>:</h4>
<p>I see. I guess I don't entirely agree that these "two kinds of unsafe" are as different as you make them sound here.</p>



<a name="218953352"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Incremental%20Approach/near/218953352" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Incremental.20Approach.html#218953352">(Dec 05 2020 at 21:00)</a>:</h4>
<p>Right, so the thing is that <code>Muckable</code> can be seen as just <code>Pod</code> where as much as possible is checked by the compiler.</p>
<p>The following is (imo) what a maximally useful "normal trait" would look like. </p>
<p><code>Muckable</code> states that a struct does not have any extra invariants beyond those required by it's fields, and it's fields all implement <code>Muckable</code>. A field is considered suitable for transmutation iff it is <code>pub</code> and <code>Muckable</code>. (For usability, an <em>exported</em> struct with all pub fields can derive <code>Muckable</code> automatically)</p>
<p>This resolves the concerns of competing indicators (partially) and partial visibility, but it wouldn't help with the others. Those are <strong>intrinsic</strong> limitations of the trait system (and some of them, such as newtyping, have been a complaint since forever). If we want a solely trait based solution without visbility, we (quite obviously) will be limited by the trait system.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>